1. Dependencies of Message Classification
Active Directory and the messaging client used are the main dependencies of message classification in Exchange Server 2010; we'll go over each of these in turn in the following sections.
1. Active Directory Configuration Container
As with all Exchange Server 2010 configurations, message
classifications are stored in Active Directory; in particular, in the
Configuration container in the path Configuration/Services/Microsoft
Exchange/<Organization>/Transport Settings/Message Classifications/<Locale>. The classifications can be verified using ADSI Edit (ADSIEdit.msc), as shown in Figure 4.
1.2. Messaging Client
The other primary
dependency for Exchange Server 2010 message classifications is the
messaging client. As stated earlier, classifications are set by the
message sender on outgoing messages in Outlook 2007, Outlook 2010, and
Exchange Server 2010 Outlook Web App and are viewable by recipients
only in those same clients.
2. Creating Message Classifications in Exchange Server 2010
New-MessageClassification -Name Privacy -DisplayName "Privacy Act" -SenderDescription
"This message contains personal information as described by the Privacy Act"
-RecipientDescription "This message contains private information of clients as defined
in the Privacy Act"
The common parameters used when creating new or configuring existing classifications are listed in Table 2.
Table 2. Message Classification Common Parameters
| CLASSIFICATION PARAMETER | PARAMETER DESCRIPTION |
|---|
| DisplayName | This parameter specifies the display name for the message
classification. This display name is shown in Outlook 2007, Outlook
2010, and Outlook Web App; it is used to select the appropriate message classification before a message is sent. The DisplayName parameter must be 64 characters or fewer. |
| SenderDescription | Provides an explanation to the sender what the message
classification is intended to achieve. This is used by Outlook and
Outlook Web App users to assist in selecting the appropriate message classification before sending a message. The SenderDescription parameter must be 1,024 characters or fewer. |
| RecipientDescription | Displays text to the recipient explaining what the message
classification is intended to achieve. This is seen by Outlook and
Outlook Web App users when a message with this classification is
received. The RecipientDescription parameter must be 1,024 characters or fewer. If this parameter is not configured, the text set for SenderDescription is used. |
| Locale | This
parameter allows you to localize the message classification for
different languages when a culture code is specified. You also must
also specify the Identity parameter of the existing message classification when you create a new locale-specific version. Values for the Locale
parameter are the string names listed in the Culture Name column in the
Microsoft .NET Class Library class reference that is available at http://go.microsoft.com/fwlink/?LinkId=67222. |
| RetainClassificationEnabled | Specifies
whether the message classification should persist with the message if
the message is forwarded or replied to; the default value for this
parameter is true. |
2.1. Creating Localized Message Classifications
Localized versions of an
existing message classification can also be created for accommodating
multilingual organizations. Exchange Server 2010 determines the
language of the recipient by examining the recipient's mailbox when a
message is classified and sent. If a message classification
in the corresponding language is found in Active Directory, the message
has that classification attached to it by Exchange Server 2010. If
there is no exact language match, Exchange examines the recipient
mailbox's locale property
to determine the locale of the recipient. In the event of no match for
the specific locale of the recipient, Exchange Server 2010 looks for a
version that is culture-neutral, such as es for es-MX, (Spanish-Mexico)
or fr for fr-CA (French-Canada). Finally, the default message classification is used if no language-specific or culture-neutral match is found, regardless of its locale.
Localized message classifications are created with the New-MessageClassification cmdlet, using the Identity parameter to identify the existing classification and the Locale parameter to indicate the locale of the new classification. For example, to create a Spanish version of a message classification named Privacy, you would use the following cmdlet:
New-MessageClassification Privacy -Locale es-ES -DisplayName "España Example"
-SenderDescription "Este es el texto de la descripción"
3. Configuring Message Classifications for Outlook 2007 and Outlook 2010
After your message
classifications have been created and configured, a few more steps are
required to allow Outlook 2007 and Outlook 2010 users to be able to set
message
classifications. You must export the classifications from Active
Directory to an XML file, and make this file accessible to the Outlook
2007 and Outlook 2010 clients. This is accomplished with the Exchange
Server 2010 EMS script named Export-OutlookClassification.ps1; this
script is located in the <install_drive>:\Program
Files\Microsoft\Exchange Server\Scripts directory on the server running
Exchange Server 2010.
After the classification XML file
is exported, Outlook 2007 and 2010 clients not only require access to
the file, but also require message
classification to be enabled. This is done through the registry by
creating the three values shown in the following example:
[HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\Policy]
"AdminClassificationPath"="c:\\Classifications.xml"
"EnableClassifications"=dword:00000001
"TrustClassifications"=dword:00000001
You must change the above
registry key to
[HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Common\Policy] for
Outlook 2010 clients. This Policy key is not present by default in
Outlook 2007 or Outlook 2010, so it must be created. Table 3 outlines the registry values configured as well as the purpose of each.
Table 3. Registry Values for Outlook 2007 and Outlook 2010 Message Classifications
| REGISTRY VALUE | DESCRIPTION |
|---|
| AdminClassificationPath | This
string value defines the location where the classification XML file is
stored. This can be any location accessible to the Outlook 2007 client,
including a network share. |
| EnableClassifications | To enable message classification functionality for the specified user, set this DWORD value to 00000001. Message classification functionality is disabled by setting this value to 00000000. |
| TrustClassifications | TrustClassifications should only be enabled for Exchange Server 2010 users, and is enabled by setting this DWORD value to 00000001. Message
classifications between users on Exchange Server 2003 are also
supported by Outlook; because Exchange Server 2003 doesn't support or
recognize message classifications, the content and validity of the message classifications is not guaranteed. In this case, disabling TrustClassifications prepends the text "The sender claims:" to the message
classification. This prevents the recipients from assuming incorrectly
that their organization has processed the classification. Disable TrustClassifications by setting this DWORD value to 00000000. |
Note:
The message
classification XML file exported from Active Directory must be
distributed to Outlook 2007 and 2010 clients, and this presents some
challenges about where to store the XML file so that it is accessible
to these clients.
Storing
the XML file in a local path on the client computer ensures that
message classifications are available to the user when they are offline
in cached mode; however, this means that the file needs to be
distributed to and updated on all of the client computers—especially if
classifications are modified or added/removed.
You
can store the XML file on a network share so that it is maintained in
only one location, but this presents challenges for those users working
offline in cached mode—they will be unable to use the message
classifications while working offline.
One
solution to this challenge is to store the file on a network share and
force that network share to be available offline for all connected
users (using Windows offline files). This ensures that message
classifications are available to end users at all times, while leaving
only one file location to maintain. When offline users connect to the
corporate network again, any changes made to the XML file will be
updated in their offline files cache.
4. Assigning Message Classifications with Transport Rules
As we've seen, with Exchange
Server 2010 and supported messaging clients you can provide end users
with the ability to assign message classifications to messages before
they are sent. In addition to this, you can automatically assign
classifications to messages using transport rules run by the Hub
Transport role based on criteria you specify. As with any transport
rules, conditions are defined for the rule and then an action is set
for the rule to take when the conditions are met; in this case,
applying a message classification. As a case in point, you could
configure a transport rule to check for messages that contain a text
pattern matching a Social Security number, then apply a message
classification named Privacy Act to ensure compliance with regulatory
and company policies.
Besides assigning
classifications with transport rules, transport rules can also be
created that act on messages that have already been classified. One
example is to prevent any messages classified Company Internal from
leaving the organization; another example would be to apply IRM
protection to messages classified Client-Attorney Privilege. What this
all means is that even though message classifications are only visible
in Outlook 2007, Outlook 2010, and Outlook Web App, your organization
may still find them of value.
